Internet Info 1994 March

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-ietf-bgpdepl-nsfnet-support-00.txt < prev next >

Wrap

Text File | 1993-03-26 | 14.4 KB | 460 lines

Network Working Group Mark Knopper INTERNET DRAFT Merit/NSFNET March 1993 Aggregation Support in the NSFNET Policy Routing Database Status of this memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." Please check the 1id-abstracts.txt listing contained in the internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the current status of any Internet Draft. 0. Abstract This memo describes plans for support of route aggregation, as specified in the descriptions of Classless Inter-Domain Routing [1] and the BGP-4 protocol [2], by the NSFNET Backbone Network Service. Mechanisms for exchange of route aggregates between the backbone service and regional and midlevel networks are specified. Additionally, the memo proposes the implementation of an Aggregate Registry which can be used by network service providers to share information about the use of aggregation. 1. Introduction The Internet network service provider community and router vendors have agreed that the time for deployment of route aggregation is very near. At the IETF meeting in November, 1992, this topic was discussed in the BGP-D, NJM and ORAD working groups; it was a discussion topic of the NSFNET Regional-Techs Meeting in January, 1993; and it was also the topic of the March, 1993 meeting of several network service providers and router vendors (see meeting summary for this recent meeting in [3]). All have generally agreed that Summer, 1993 is the time to enable BGP-4 and CIDR aggregation. Each of the parties are responsible for their own aspect of CIDR implementation and practice. This memo Expiration Date September 1993 [Page 1] RFC DRAFT March 1993 describes Merit's plans for support of aggregation on the NSFNET, and a proposal for implementing a database of aggregate information for use by network providers. 2. Aggregation Support by the Backbone Service The NSFNET backbone service includes a Policy Routing Database system which currently holds the set of network numbers that are accepted by the backbone service with a list of Autonomous System numbers from which announcements of these network numbers are expected. For the CIDR implementation the database system will be modified to allow aggregation of routing information to be configured. When the NSFNET service announces routes to regional peers, de-aggregation will not be done. If a peer needs to receive full routing information the peer should run the BGP-4 (or later IDRP) protocol which supports CIDR. 2.1 Current Configuration Capabilities An example of the way a network number is currently configured is as follows: 35 1:237 2:233 3:183 4:266 5:267 Or, using the syntax proposed by the Yu, Chen and Rekhter in "Inter- Domain Routing Policy Description and Sharing" [4], this would be better specified as: ACCEPT dst 35 and AS_path 237 = 1 ACCEPT dst 35 and AS_path 233 = 2 ACCEPT dst 35 and AS_path 183 = 3 ACCEPT dst 35 and AS_path 266 = 4 ACCEPT dst 35 and AS_path 267 = 5 This shows that network number 35 (ie. 35.0.0.0, a class A net number) is configured on the T3 backbone such that it can be reached via 5 autonomous systems. The primary path is via AS 237, secondary is via AS 233, etc. 2.2 New Configuration Features for Aggregation There will be three new capabilities for which the backbone service can be configured to support aggregation. The first two allow aggregates to be stored in the backbone routing tables based on announcements by the regional network (autonomous system or AS) peers. The third allows the announcement of aggregates to the AS neighbor peers. The following sections give examples of the three features: Expiration Date September 1993 [Page 2] RFC DRAFT March 1993 2.2.1 NSFNET accepts aggregates In this case the regional peer router is CIDR-capable (runs BGP-4) and the announcement comes into the backbone as an IP address prefix. An example of the first method is as follows. The syntax for ACCEPT can be modified to handle aggregates as well as single networks. ACCEPT dst <192.64.128 17> AS_path 189 = 1 ACCEPT dst <192.64.128 17> AS_path 24 = 2 ACCEPT dst <192.64.128 17> AS_path 267 = 3 Or a more compact way of storing the info might be more similar to the current NSFNET database: <192.64.128 17> 1:189 2:24 3:267 In this example, independent of the "class" of IP network number, an aggregate containing network addresses matching a pattern in which the first 17 bits match the prefix 192.64.128 will be accepted in announcements to the NSFNET service. Primary path to destinations covered by the prefix is expected via AS 189, secondary via AS 24, etc. 2.2.2 NSFNET announces aggregates Currently the NSFNET database has a list of AS's or network numbers for each neighbor AS that are announced by the backbone to that AS. These announcements are specified currently by "announcetoAS" statements submitted by midlevels to Merit, and then included in the ANSnet router configuration files. There are two forms of these statements. The first form uses the "norestrict" clause and indicates that all of the network numbers within each AS in the list should be announced to the neighbor midlevel AS. For example: announcetoAS 42 norestrict ASlist 22 26 38 60 68 In this example, the NSFNET is configured to announce to neighboring midlevel AS 42, all networks in the routing table that were announced from AS's 22, 26, 38, 60 and 68. If the "norestrict" keyword is changed to "restrict", this indicates that an explicit list of network numbers for the AS's in the list is specified in the configuration file. The NSFNET will only announce network numbers that were announced by the AS's in the list, *AND* that appear in the "restrict list" of network numbers submitted separately by the midlevel. This system will continue to work once aggregation is implemented. The norestrict (or equivalent keyword once the new software is deployed) function will specify that all network reachability Expiration Date September 1993 [Page 3] RFC DRAFT March 1993 information received from a set of Autonomous Systems, including any aggregates, will be announced. Depending on implementation in the gated software, it may also be possible to provide more specific restrictions on which aggregates reachable within an AS will and which will not be announced to a neighbor AS. Again using syntax similar to what is described in the RPDL paper, the following examples can be used to describe outbound aggregation policy: ANNOUNCE dst <192.64.128 17> to 22 The above specifies that the given aggregate is announced to neighbor AS 22. ANNOUNCE * AND (! dst <193 16>) to 42 The above example uses a logical expression style and specifies that all ("*") networks or aggregates with the exception of 193.0.0.0 mask 255.255.0.0 are announced to neighbor AS 42. More elaborate announcement policies can be imagined. This discussion provides examples of what might be available but it has not been resolved yet just what capabilities will be offered initially. 2.2.3 NSFNET aggregates by proxy The other method is where the backbone is configured to perform aggregation on behalf of a CIDR-incapable regional. An example of this aggregation technique is: AGGR <192.64.192 AND 192.64.129> => <192.64.128 17> ACCEPT dst <192.64.128 17> and AS_path 189 = 1 ACCEPT dst <192.64.128 17> and AS_path 267 = 2 In this example, the same class-independent set of IP addresses will be stored and propagated within the backbone as an aggregate under a set of conditions. This example has the conditions such that when both networks 192.64.192 and 192.64.129 are made to the backbone (through either AS 189 or AS 24 or AS 267) it will aggregate the whole block. If only one of the networks is announced to the backbone, no aggregation will be performed. In this case additional ACCEPT clauses may be present which allow acceptance of the single network numbers. Expiration Date September 1993 [Page 4] RFC DRAFT March 1993 3.0 Aggregate Registry In discussions with network providers it has become apparent that there is a great need for sharing of aggregate information globally. In addition to implementing the capability of including aggregation information in the NSFNET Policy Routing Database (as described in section 2), there is a need to have a separate database that will allow aggregate information from any Autonomous System to be stored and made available for easy electronic retrieval. The information can be used for routing coordination and policy configuration in the larger inter-domain context. One of the expected uses of such a database is to help determine the granularity of aggregation of network reachability information with respect to policy. It may be desirable in some cases to aggregate broadly, for example all networks whose numbers conform to a binary prefix pattern within an entire nationwide network. This case may be rare since it may be unlikely that there is a backbone whose routing policy is the same for all of its constituent networks. Some of this depends on how network number allocation has been handled, or whether the network provider has renumbered its client networks to conform to CIDR aggregation boundaries. Rules for network number allocation with CIDR are discussed in [5] and [6]. Merit proposes to implement an "Aggregate Registry" to provide sharing of aggregate information for the Internet inter-domain routing community. Initially this will be a simple database without much structure. It is not intended to hold only aggregates which are announced or accepted by the NSFNET service, rather it should be a community registry that all will be invited to use and make use of. The Aggregate Registry will consist of a list of aggregate announcement statements. Each statement consists of three types of information, along with contact information: 1) The aggregate identifier, consisting of a network number prefix and the prefix length. For example <192.29.128 16>. 2) The source AS number for the aggregate. That is, the AS number of the network service provider that initially aggregates the network reachability information into the aggregate for announcement to its neighbors. 3) A list of neighbor AS's to whom the aggregate will be announced by the source AS. 4) Contact information, eg. e-mail address and name or NIC handle of the administrative and technical contacts for the source AS. Thus, a given aggregate is only listed once in the table by the source AS. Expiration Date September 1993 [Page 5] RFC DRAFT March 1993 Note that this registry reflects both the simple list of aggregates that are supported by the union of network providers, as well as providing information on inter-domain topology for the Internet. Merit will implement procedures for aggregates handled by the NSFNET to be registered here as well as procedures for updating the information when routing announcements change. Requests to update the information will be handled by e-mail to a staff mailing list at Merit. 4.0 Conclusions and Next Steps Implementation of CIDR is underway, and there is still a fair amount of planning and discussion that is needed for a successful transition. Merit is proposing specific functions for CIDR aggregation that will be supported by the NSFNET, as well as an Aggregate Registry that can serve as the basis for inter-domain routing coordination for CIDR. Once this paper is discussed, Merit and ANS will make a specific description of CIDR functionality in the NSFNET service and ANS backbone available. The policies and administrative procedures as well as the technical capabilities of the backbone need to be defined. The Aggregate Registry will allow a set of tools to be developed that can facilitate the design of aggregation policy. A query tool to allow lookup of aggregation information for a given network or aggregate would be very useful. It will also be possible to undertake to write an inter-domain topology mapping program based on the source and destination AS announcements stored in the Registry. References [1] Fuller, V., Li, T., Yu, J., and Varadhan, K., `Supernetting: an Address Assignment and Aggregation Strategy', RFC1338, June 1992. Update, Work in Progress. [2] BGP-4 protocol [3] Topolcic CIDR meeting [4] J. Yu, E. Chen, Y. Rekhter, "Routing Policy Description and Sharing", Expiration Date September 1993 [Page 6] RFC DRAFT March 1993 Work In Progress, March 1993. [5] Gerich, E., `Guidelines for Management of IP Address Space', RFC1366, October 1992. Update, Work in Progress. [6] Rekhter, Li RFC on Net Allocation Guidelines Expiration Date September 1993 [Page 7]